Preserve absent Gemfile lock paths - #3118

Thank you, the change itself is right and I am planning to merge it. One correction to the description, for the record.

nil.to_s does not raise; it returns "". So nothing blows up at serialization time. What actually goes wrong is quieter, and it happens on the way back in:

1. to_lockfile writes gemfile_lock_path: '' when gemfile_lock_path is nil.
2. Lockfile.from_lockfile tests if p = data["gemfile_lock_path"], and "" is truthy in Ruby, so it builds Pathname("") instead of leaving the path absent.
3. gemfile_lock_fullpath then returns lockfile_dir + Pathname(""), which is lockfile_dir itself.
4. LockfileGenerator#validate_gemfile_lock_path! compares that directory against the real Gemfile.lock and raises GemfileLockMismatchError.

So the bug is a wrong value round-tripping through the lockfile rather than a NoMethodError, and &.to_s is the right fix because lockfile_data already declares "gemfile_lock_path" => String?.

It is also worth noting that LockfileGenerator always passes definition.lockfile.relative_path_from(lockfile_dir), so rbs collection itself never reaches this today. It matters for callers that build a Lockfile directly, and for a lockfile written before we added the key.

I have rebased the branch onto the current master. The test (head, stdlib_test rubocop) failure was an unrelated Net::HTTP test on ruby-head and is fixed there now.